Development with Stratified Frameworks

ions as aspect anchors Because concerns are irrelevant until the developer requires a certain level of detail, we can define a concern’s corresponding aspect in terms of the system abstractions inhabiting the stratum in which the concern first appears. One of the main challenges for weaverbased aspect-oriented approaches operating at the code level3 is expressing where in the code to apply an aspect. Developers currently use declarative patterns to match locations in the base code to determine the join points between base code and aspect. The problem with this approach is that the patterns can only use abstractions from the implementation domain—typically methods, classes, and packages. Any higher-level system abstractions must be recreated, for example by the systematic use of naming conventions. In a stratified architecture, you can anchor an aspect to system abstractions at the relevant level. In general, the abstraction level at which a concern becomes relevant usually offers semantically richer abstrac8 6 I E E E S O F T W A R E h t t p : / / c o m p u t e r. o r g / s o f t w a r e Weaver-based approaches operating on code artifacts completely separate aspect code from base code. This strength, however, is also a weakness: when several aspects and the base code interfere at the same join points, issues of priority, nesting, and mutual exclusion arise. All separation-of-concerns approaches that use a low-level code structure have difficulty defining join points in terms of higher-level system abstractions because they must recreate these abstractions from the flat code structure. Furthermore, weaver-based technologies have only just begun to define aspects based on other aspects rather than the base code, whereas the hierarchical organization of concerns is a built-in feature of stratification. Our architecture stratification approach currently lacks dedicated tool support, but it can benefit the development process even if applied manually. Although manually applying stratification requires developers to explicitly work with tangled specifications, this is a natural consequence of abstraction. Some aspect interferences must be dealt with manually, and the lower strata are the best place to do this effectively. Another approach for making a framework aspect-aware is to provide aspect functionality (such as an AspectModerator class) within the framework.1 This requires neither an aspect nor an annotation language. Furthermore, by deferring weaving to runtime, even the dynamic addition and reconfiguration of aspects becomes possible. Unlike stratified frameworks, however, this approach does not provide any leverage in terms of abstraction levels and can suffer from more efficiency problems than com-